Closes #805.

The bug

admin_cancel_action refunded the seller's escrow before it finished validating the request:

if order.hash.is_some() {
    ln_client.cancel_hold_invoice(hash).await?;   // irreversible
}
...
let dispute_initiator = match (order.seller_dispute, order.buyer_dispute) {
    (true, false) => "seller",
    (false, true) => "buyer",
    (_, _) => return Err(MostroInternalErr(ServiceError::DisputeEventError)),  // rejects — too late
};

When neither initiator flag is set (or both are), the handler returns DisputeEventError — but cancel_hold_invoice has already returned the funds to the seller. The order stays in Dispute, the transition to CanceledByAdmin never runs, and the dispute row is never moved to SellerRefunded. The Lightning side and the DB disagree permanently, and the refund cannot be undone.

The fix

Move the initiator resolution above the refund, so every check that can reject the call runs before the escrow is touched. This is the same ordering discipline already applied to the status guards and the bond-resolution validation just above it (see the existing Phase 2 comment). The valid path — a legitimately flagged initiator — is unchanged.

Test

New regression test dispute_without_initiator_flag_errors_before_refunding: an order with a hold-invoice hash and no initiator flag must fail with DisputeEventError and be left in Dispute.

The test is a genuine before/after discriminator thanks to the existing dead_lnd() harness (a real LndConnector against a dead endpoint, so any RPC fails fast):

• Before the fix it failed with Err(MostroInternalErr(LnNodeError("code=Unknown message=client error (Connect)"))) — proof the refund RPC had already been dispatched.
• After the fix it returns DisputeEventError without ever reaching LND.

dispute_with_hash_reaches_ln_cancel_seam still passes, confirming the legitimate refund path is untouched.

Verification

• cargo test — 1016 passed, 0 failed
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt --all — clean

Note

admin_settle.rs has related ordering/CAS concerns tracked separately in #809 and #810; this PR deliberately stays scoped to #805.

Manual testing

The unit tests pin the ordering at the handler seam; this is how to reproduce
the bug and verify the fix end to end against a real LND. The single
observable that matters throughout: on a request that is going to be
rejected, the hold invoice must still be ACCEPTED afterwards.

0. Environment

• LND on regtest (Polar) + a local relay: cd docker && make docker-up
  (see docker/README.md), or cargo run against Polar directly.
• A solver key with read-write permission (admin-add-solver), plus
  mostro-cli for the maker/taker/solver messages.
• Optional but recommended for test E: [rpc] enabled = true in
  settings.toml, so CancelOrder can be driven over gRPC and the error is
  returned to the caller instead of only logged.
• Build the branch: git checkout fix/admin-cancel-validate-before-refund && cargo run

Inspection helpers used below (<ID> = order id, <HASH> = orders.hash):

sqlite3 mostro.db "select status, hash, seller_dispute, buyer_dispute, \
  seller_pubkey is null as no_seller, buyer_pubkey is null as no_buyer \
  from orders where id='<ID>';"
sqlite3 mostro.db "select id, status from disputes where order_id='<ID>';"
sqlite3 mostro.db "select role, state from bonds where order_id='<ID>';"   # only if the bond feature is on
lncli --network regtest lookupinvoice <HASH>       # .state: ACCEPTED | CANCELED | SETTLED

1. Common setup — a disputed order with a live escrow

1. Maker publishes an order, taker takes it.
2. Seller pays the hold invoice → lncli lookupinvoice <HASH> shows
   ACCEPTED; buyer sends the payout invoice; buyer sends fiat-sent.
3. Either party sends dispute.
4. Solver sends admin-take-dispute.

Checkpoint before every test below: orders.status = dispute, exactly one
of seller_dispute / buyer_dispute is 1, orders.hash is set,
disputes.status = in-progress, invoice state ACCEPTED, any bond rows
locked.

2. Test A — the legitimate path is unchanged (regression guard)

Send admin-cancel for the order as the assigned solver.

Must all hold to approve:

• lookupinvoice <HASH> → CANCELED (escrow returned to the seller).
• orders.status → canceled-by-admin.
• disputes.status → seller-refunded.
• A kind-38386 event is published with s = seller-refunded and
  initiator = <the side that actually opened the dispute> — this tag must
  match the flag set in step 1.3, not an arbitrary side.
• Solver, seller and buyer all receive the admin-canceled DM.
• Bond rows (if enabled) leave locked → released (or slashed when a
  BondResolution was attached).

3. Test B — ambiguous initiator must not touch the escrow (the #805 bug)

The flags are only corruptible out of band, so force the state directly on a
freshly disputed order (repeat §1):

sqlite3 mostro.db "update orders set seller_dispute=0, buyer_dispute=0 where id='<ID>';"

Send admin-cancel. Must all hold:

• lookupinvoice <HASH> → still ACCEPTED. (On main this returns
  CANCELED: the seller was refunded on a request that was then rejected.)
• orders.status → still dispute; disputes.status still
  in-progress; bond rows still locked.
• The daemon logs
  admin_cancel: ambiguous dispute initiator flags; refusing before the escrow is touched
  with order_id, seller_dispute=false, buyer_dispute=false.
• Over gRPC the call fails with Admin cancel failed: … DisputeEventError;
  over Nostr the daemon logs the warning and no admin-canceled DM is
  emitted to anyone.
• Retry proof: restore the correct flag
  (update orders set seller_dispute=1 …) and re-send admin-cancel → it
  now completes exactly as in Test A. Nothing was stranded by the rejection.

4. Test C — both flags set is equally ambiguous

Same as Test B, but set seller_dispute=1, buyer_dispute=1. Same expected
result: rejected, invoice ACCEPTED, order dispute, same log line with
seller_dispute=true, buyer_dispute=true. (Pre-fix this arm also refunded
first.)

5. Test D — missing counterparty pubkey is rejected before the refund

On a fresh disputed order:

sqlite3 mostro.db "update orders set buyer_pubkey=NULL where id='<ID>';"

Send admin-cancel. Must all hold:

• Rejected with InvalidPubkey; lookupinvoice <HASH> → still
  ACCEPTED; orders.status still dispute; disputes.status
  unchanged; bond rows still locked.
• Restore the pubkey and re-send → completes as in Test A.

(On main this rejection happened after the refund, after the dispute row
was moved to seller-refunded and after the order became
canceled-by-admin — past the point where a retry is possible, since the
Dispute status guard rejects the second attempt, leaving the bonds
Locked with no reconciler.)

6. Test E — a failing DM must not abort the bond resolution

Needs [rpc] enabled = true so the command does not travel over the relay
that is about to be stopped.

1. Set up a disputed order per §1, with the bond feature enabled so there are
   locked bond rows.
2. Stop the relay (docker compose stop nostr-relay).
3. Call CancelOrder over gRPC.

Must all hold:

• The gRPC call returns success.
• The log shows admin_cancel: failed to notify the admin/seller/buyer of the cancellation: … (one line per undelivered recipient) — and execution
  continues past them.
• orders.status = canceled-by-admin, invoice CANCELED, and critically the
  bond rows are no longer locked.
  (On main the first send_dm error returned early, so the bonds stayed
  Locked with no retry path.)

7. Test F — admin-settle got the same treatment

Fresh disputed order per §1 (buyer payout invoice present), then corrupt the
flags as in Test B and send admin-settle.

Must all hold:

• Rejected with DisputeEventError; log line
  admin_settle: ambiguous dispute initiator flags; refusing before the escrow is settled.
• lookupinvoice <HASH> → still ACCEPTED, i.e. not SETTLED — the
  seller's escrow was not captured. orders.status still dispute.
• Restore the flag and re-send admin-settle → the invoice goes to
  SETTLED, the order leaves dispute (settled-hold-invoice, then the
  payout to the buyer), disputes.status = settled, and the admin-settled
  DMs go out.

8. Approval criteria

Approve only if every criterion below is observed:

Reject if any rejected request shows a CANCELED/SETTLED invoice, an order
that left dispute, a bond stuck in locked after a successful cancel, or a
retry that is refused after the underlying row was repaired.

Optional before/after: run tests B and D against main first — the
invoice ends CANCELED while the order stays in dispute, which is the
exact split-brain #805 describes.

Summary by CodeRabbit

• Bug Fixes
  • Improved dispute cancellation validation: now rejects missing/ambiguous dispute initiator and invalid counterparty pubkeys before any refund/cancellation side effects, keeping disputed orders in Dispute for safe retries.
  • Improved dispute settlement flow: determines dispute initiator before irreversible settlement and errors out early on corrupted/ambiguous initiator flags.
  • Made admin/seller/buyer notification fan-out best-effort so messaging failures no longer abort completion.
• Tests
  • Added/extended regression tests for cancellation (issue #805) to verify early failure ordering and unchanged Dispute status; added a settlement pre-check test for missing initiator flags.